在談過MLOps在廣泛的定義，以及拆分成團隊、技術、流程三個面向之後。想必大家也開始思考，一個好的專案和解決方案應該要長什麼樣子，有沒有哪些規範可以參考、有沒有一些企業案例可以學習。
今天透過AWS的技術白皮書，帶大家看看：什麼是技術白皮書、針對決策期、導入/執行期、驗收期，各有哪些資源可以參考。一起學習，在雲端的環境上，一個架構完善解決方案的完整樣貌，以及針對MLOps的面向上，解決方案可以怎麼設計以及實踐。
近幾年隨著B2B與B2C的技術與商業採購複雜度不斷增加，對於決策者來說，面臨的局勢變動得更快，須考慮的因素也更多了。因此研究報告、白皮書等內容，佔據了決策早期的重要因素之一。根據2018與2021的內容偏好報告指出(1)71% 的受訪者使用白皮書作為從可靠來源獲取洞察力的一種方式。(2)企業在做決策的初期，白皮書是所有資料來源當中比重最重的，佔了57%。[6]
＊圖片來源:2021內容偏好報告
技術白皮書內容通常來自該領域的相關經驗者所撰寫，通常是由技術公司提供的教育訓練和吸引潛在客戶的其中一環，協助公司在目標受眾建立可信度與分享知識。內容大部分陳述的該產業的現況、問題，進而講述解決方案，有些也包含案例分享。 如同這篇分享的AWS技術白皮書，可在官網找到之外。若你是使用其他雲服務，也能在該公司官方網站找到相對應的白皮書或者最佳實踐建議。技術白皮書本身僅供參考、案例分享，但不會有程式碼這樣細節的內容。各公司在實作的時候，還是會需要依照業務邏輯修正、調整。
第一次閱讀白皮書的讀者，通常會被冗長的篇幅嚇到。像是架構完善框架白皮書(AWS Well-Architected Framework)有79頁PDF。而MLOps：持續交付的機器學習白皮書(MLOps: Continuous Delivery for Machine Learning on AWS)也有69頁PDF的長度。
如果在開始閱讀之前，腦中已經有幾個問題想解答，會讓整份文件的閱讀輕快許多。如果要說是核心觀念的話，就是把架構完善框架的五個支柱，應用到ML專案上。這五個支柱分別是：(1)卓越營運(2)安全性(3)可靠性(4)效能達成效率(5)成本優化。詳細細節可以到架構完善框架白皮書閱讀。
在這個框架下，退一步來思考，把整個專案分幾個階段來討論：(1)決策期(2)導入期(3)驗收期
這個階段整個團隊都屬於正在做功課、了解現況的階段，但是基於每個角色在專案的角色不同、背景不同、各自做功課的方向也都不大相同。
(a)決策者： ML正在從實驗階段擴展到標準業務流程，幫助企業增加收入並降低成本。 決策者在初期階段會想了解資源的分配與使用，例如一個解決方案的月支出、年支出大約多少，帶來效益為何，安全性以及合規性需注意哪些。推薦閱讀：
(b)DevOps： 在已經具備有DevOps的經驗下，搭配Iguazio CTO在CNCF的一場演講。從DevOps的角度來學習，可以怎麼透過git 的CICD流程協助ML專案。並且在前期與ML團隊溝通需要的開發環境，以便於能夠設置讓ML團隊能夠順利開發的環境。確保在開始實作的時候，能有相關的技術支撐，有很好的開發與產品品質。建議閱讀：
(c)資料科學家與資料工程師： 在專案的初期需要專注在商業問題與ML問題的對應以及資料的來源與品質，這會讓ML團隊與專案負責人、決策者有大量的溝通。確保公司已收集足夠品質、數量的資料。並且與公司的資料安全專家合作，確保資料如何流進ML團隊以及相關授權。建議閱讀：
(a)決策者： 當決策者已評估，決定一個專案要開始實作，過程當中就不會干涉太多。最多會關注幾個重要的指標，這些指標可從MLOps 帶給商業與技術流程的5個好處與12個指標複習。
(b)DevOps： 在開始執行的時候，DevOps團隊也扮演了非常重要的角色(個人覺得跟ML團隊一樣重要)。假若公司團隊決定將ML專案的資源架在k8s上，DevOps團隊需要負責維運一個或數個k8s集群，包含授權、安全性、軟硬體資源規劃等。若是把服務都放在雲託管服務(managed service)，那麼DevOps團隊肩膀上的負重就會少一些。DevOps在這階段則需要學習，如何將既有的devops mindset帶到這個ML專案上。建議閱讀：
(c)資料科學家與資料工程師： 在這階段會需要和DevOps大量的溝通，從實驗的版本控制、交付程式碼時候所應該啟動的測試與驗證、以及每次模型進到產品的開發管線(pipeline)的維護。資料科學家除了過去既有的ML知識之外，也需要補充許多跟產品交付相關的知識。建議閱讀：
這一階段雖然說是驗收期，但也可以說是展開下一次迭代的準備期。盤點目前做到的狀況，與預期期待落差相距多少。規劃下一次的執行期。
(a)決策者： 須從大方向看目前的專案進程，在MLOps的成熟度有多少。(之後再補充一篇"不同階段成熟度的MLOps指標"好了。)除了在商業指標與技術指標之外，專案的社會影響力，像是公平、安全、偏見和可持續性問題等等的問題，也都是大家持續關注的內容。在ML發展的過程當中，當使用了更強大的模型之時，是否也提供一項能幫助到弱勢群體、確保所有任機會均等的方式，來協助使用者們。
(b)DevOps： 除了ML專案的穩定交付之外，DevOps團隊也能夠和ML團隊一起看MLOps Principles，回過頭確認在測試、服務監控等方面是否都已經完善。並且參照MLOps: Operationalizing Machine Learning on AWS - AWS reference architecture - AWS reference architecture，在模型建立、模型產品化、測試與品質控管、部署、監測以及將整個使用者回饋能夠整合成閉鎖開發循環。
(c)資料科學家與資料工程師： ML團隊則是在驗收期需要盤點在模型開發、模型部署以及維運上是否有完整的開發週期、如何收集使用者的資訊與反饋，持續改進現有的系統。除了在架構的完整性需要與DevOps溝通與對齊之外，與決策者也需要相互對齊，商業相關的指標是否都有在這次交付被滿足，有哪些關鍵的資料點會是我們想在下一次迭代的時候關注等等。推薦閱讀：
今天整理了數個技術白皮術，希望大家在有空的時間可以思考一下，自己目前所在的專案狀況，依照自己的需求列下幾個問題，到白皮書裡面找答案。如果願意分享的話也可以在文章下方留言或聯繫我分享你的經驗與問題。
Reference
[1]. The Ultimate Guide to Writing Technical White Papers
[2]. MLOps Architecture Guide - neptune.ai
[3]. AWS Well-Architected Framework - AWS Well-Architected Framework
[4]. MLOps: Operationalizing Machine Learning on AWS
[5]. AWS Whitepapers & Guides
[6]. 2021 Content Preferences Survey
[7]. The balancing act of AI in the enterprise
iThome鐵人賽
看影片追技術